The present disclosure relates to migrating data from a source system in stages to a destination system in an automated fashion using a remote migration controller that is not local to the source system.
Migration of large amounts of data in one effort, as opposed to completing the process in stages, may take an undesirably long time and may place a heavy burden on technical support services when even a small fraction of the data migration results in errors. In the case of a large-scale email and data migration, there may also be a heavy impact on the staff in charge of setting up email and data on each end user's computer. These problems are highlighted in the following examples,
A company may have, for example 2500 employees around the world in 20 different offices, and every employee in the company is to have their email and associated account data (e.g. contact cards, calendar appointments, distribution groups, permissions, etc.) migrated from one system (hereinafter referred to as a “source system”) to a destination system. If this migration were performed in a single effort, limitations on bandwidth and system resources would likely create bottlenecks that would extend the total amount of time spent migrating the data to an undesirable length. Further, the logistics of migrating 2500 people in different times zones may be complicated in that some of them may be working on their computers while the migration is occurring, which could cause errors or unwanted interruptions. And, if even a small percentage of users experience errors or interruptions during the migration, it could still be a large enough group to quickly overwhelm the technical support staff in charge of managing the migration, further extending the time and expense of completing the job. The task of setting up every end user's email and data alone could be enough to overload the technical support (“IT”) staff.
The problems outlined above may be alleviated by performing data migrations in stages, e.g., by migrating subsets of data at different times until everything is moved to the destination system. Staged migrations, however, may require those who are tasked with carrying out the staged migration (hereinafter referred to as “partners”) to create in advance batch files or other scripts that execute commands to implement the migration. This can require a wealth of information from both the source and destination email and data systems, can be very time consuming, and can leave much room for error.
Also, with many migration jobs, remote access cannot be attained to run the above-described command scripts, and in those scenarios, partners may generally be on the premises of the source system to execute the commands, in a time-sensitive fashion (this is sometimes referred to as a “hybrid” migration). Many systems are behind firewalls or have other access restrictions for remote access. In order to do this, work may need to be done to upgrade the source system and an additional server or servers may need to be bought and installed on the premises of the source system. This can create additional cost and time to carry out the migration, and also can increase complexity and thus can create more room for error. For example, in a staged email migration where remote access is not possible, partners could have to be on premises to manually configure every single mailbox at the appropriate time. The partner could need to set up mail routing rules before migration time, which can be problematic because it may be difficult to get end users switched over to the destination system fast enough to avoid emails being undelivered while the migration is happening. Mail routing rules can comprise forwarding rules to forward emails from one place to another.
Another challenge with staged migrations is that there are multiple kinds of source systems for managing data including but not limited to email, files, calendaring (e.g. Microsoft Exchange®, Google®, etc.). Each of these systems has different commands that need to be executed against them in order to perform the migration. Staged migration tools often do not have the ability to detect which type of source system is present and do not have the flexibility to work with the multiple systems that may be detected (i.e. run the appropriate commands for multiple systems that may be detected).
Therefore, it is desirable to provide improved systems and methods of conducting staged migrations to address the above and other problems.